-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document the approach for resizing and deleting devices #1
Document the approach for resizing and deleting devices #1
Conversation
In any case, note that resizing a partition can be limited depending on its content, the filesystem | ||
type, etc. | ||
|
||
Combining `search` and `resize` is enough to indicate Agama is expected to resize a given partition |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's elaborate a bit in the most technical part how all this could be achieved.
Let's start with a small reminder on how resizing works in the current SpaceMaker.
class Proposal::PartitionsDistributionCalculator
# [...]
# Space that should be freed when resizing an existing partition in order to have a good chance
# of creating a valid PartitionsDistribution (by means of #best_distribution).
#
# It does not take the limitations of the partition into account (eg. whether it can be
# resized or how full it is)
def resizing_size
# This tries to create valid distributions
# If resizing does not result in any valid distribution, returns current size
end
end
class Y2Storage::Proposal::SpaceMakerActions::Shrink
# @return [DiskSize] size of the space to substract ideally
attr_accessor :shrink_size
# Reduces the size of the target partition
#
# If possible, it reduces the size of the partition by {#shrink_size}.
# Otherwise, it reduces the size as much as possible.
#
# This method does not take alignment into account.
def shrink(devicegraph)
[...]
end
end
Taking that into account, the following steps/changes could be inserted in the general AgamaProposal
algorithm to handle all the reasonable situations.
First of all, Beware the usage of "current" can lead to strange situations like:
- Real size: 10 GiB. Min: "current". Max: 5 GiB
Those cases should be watched. The steps below assume that does not happen.
Step 1. When calculating the SpaceMaker actions, generate one shrink for every partition in which min is smaller than the current size.
How to determine the size of the shrink action?
suggested = current - calculator.resizing_size
target_size =
if min > suggested
min
elsif max < suggested
max
else
suggested
end
The action is mandatory if the max is smaller than the current size. Otherwise is optional.
Step 2. To be done on every attempt. That is:
- Before starting with the optional actions and also after every action
- Before calculating the corresponding distribution
- For all partitions that need to grow (that can be optimized, not all partitions are affected by each action)
def needs_to_grow?(partition)
partition.min > device_at_working_devicegraph(partition.found_device).size
end
if needs_to_grow?(partition)
immediately_try_to_grow_up_to_min(partition)
# Maybe it would be useful to remember the result
#
# It can fail because there is still not enough space, then that distribution is not valid
# and we need to keep trying stuff.
#
# It can fail because there was space but something else at resize_info prevents
# the partition from growing.
# Should we abort? I guess so, that's what "min" means after all.
end
Step 3. When distributing extra space at the end of the algorithm
Take into account partitions that could_grow and are right before the space
def could_grow?(partition)
partition.max > partition.current && partition.resize_info.max_size > partition.current
end
A general notes regarding the order in which we decide what to delete: maybe we should prioritize to delete partitions that are after a partition that needs to grow. If I remember correctly, the only criteria is starting by the end of the disk, but it could be way smarter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea. The only specific actions are about deleting. The rest is inferred from the declarative properties (e.g., filesystem, size, etc).
In fact, there could be different schemas:
Partition
Search
Delete
Partition
Search
Size
DeleteIfNeeded
Partition
Search
Size
Filesystem
That would avoid having incompatible configs like indicating Delete
and DeleteIfNeeded
at the same time.
joseivanlopez#1 documented the approach to follow for resizing partitions at Agama, based on the partitioning config (a.k.a. the "profile"). The current pull request implements the basis of the described management. It depends on the improvements introduced at yast2-storage-ng by yast/yast-storage-ng#1388 ### Pending Some aspects of partition growing are not fully handled. That's planned for a future iteration and documented at https://trello.com/c/opInsicQ/531-storage-profile-partition-growing
Created as a pull request on top of agama-project#1455.
This describes the way to approach to resizing in the auto-format of Agama.